Wie bei jedem Penetrationstest beginne ich mit der Reconnaissance-Phase, um das Zielsystem im Netzwerk zu identifizieren und erste Informationen zu sammeln. Das Ziel ist es, die IP-Adresse des Systems "Atom" zu finden.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ :::::::::::::::::::::::::::::::::: ARP-Scan :::::::::::::::::::::::::::::::: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ 192.168.2.58 08:00:27:69:48:a6 PCS Systemtechnik GmbH
Analyse: Ich verwende arp-scan -l (der Befehl selbst ist im Originaltext nicht gezeigt, aber der Kontext des "ARP-Scan" Headers und der Ausgabe lässt darauf schließen), um das lokale Netzwerk zu scannen. Die Ausgabe zeigt eine IP-Adresse, eine MAC-Adresse und den Hersteller der Netzwerkarte. Die IP-Adresse 192.168.2.58 ist dem Hersteller PCS Systemtechnik GmbH zugeordnet, was, wie wir aus früheren Tests wissen, oft auf eine virtuelle Maschine hindeutet.
Bewertung: Der ARP-Scan hat das Zielsystem schnell und effektiv identifiziert. Die IP-Adresse 192.168.2.58 ist nun unser Angriffsziel. Die Information über den MAC-Hersteller ist nützlich für die Systemidentifikation, aber nicht direkt für die Kompromittierung relevant.
Empfehlung (Pentester): Die Ziel-IP-Adresse ist bestätigt. Ich werde sie nun in meine lokale Hosts-Datei eintragen, um die folgenden Schritte zu vereinfachen.
Empfehlung (Admin): Eine grundlegende Netzwerksegmentierung und die Überwachung von ARP-Verkehr können helfen, die schnelle Identifizierung von Hosts im lokalen Netzwerk durch Angreifer zu erschweren.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ /etc/hosts... 192.168.2.58 atom.hmv
Analyse: Ich füge einen Eintrag in meine lokale /etc/hosts Datei ein, um die IP-Adresse 192.168.2.58 dem Hostnamen atom.hmv zuzuordnen. Dies geschieht normalerweise mit einem Editor wie vi oder nano, obwohl der genaue Befehl hier nicht gezeigt ist, ist die Konsequenz klar. Die 'O'-Korrektur wurde angewendet, um "hsts" zu "hosts" und "atm.hmv" zu "atom.hmv" zu korrigieren.
Bewertung: Das Hinzufügen eines Hostnamen-Eintrags in die /etc/hosts Datei ist ein standardmäßiger Vorbereitungsschritt, der die Lesbarkeit von Befehlen und die Organisation des Tests verbessert. Es hat keinen Einfluss auf die Sicherheit des Zielsystems selbst.
Empfehlung (Pentester): Ich kann nun den Hostnamen atom.hmv in meinen Befehlen verwenden, was die folgenden Schritte übersichtlicher macht. Der nächste Schritt ist die detaillierte Port- und Dienst-Enumeration.
Empfehlung (Admin): Stellen Sie sicher, dass interne DNS-Informationen nicht nach außen dringen und dass öffentliche DNS-Einträge nur die notwendigen Informationen enthalten.
Als Nächstes führe ich einen UDP-Scan mit Nmap durch. UDP-Dienste werden von TCP-Scans nicht erfasst und können potenziell interessante Angriffsflächen bieten.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ::::::::::::::::::::::::::::: Nmap UDP Scan ::::::::::::::::::::::::::::::: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-23 20:18 CEST Nmap scan report for 192.168.2.58 Host is up (0.00029s latency). Not shown: 993 open|filtered udp ports (no-response) PORT STATE SERVICE 623/udp open asf-rmcp 19415/udp closed unknown 19489/udp closed unknown 19500/udp closed unknown 21016/udp closed unknown 34038/udp closed unknown 34579/udp closed unknown MAC Address: 08:00:27:69:48:A6 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 1.49 seconds
Analyse: Ich führe einen Nmap UDP-Scan durch (vermutlich mit nmap -sU -p- 192.168.2.58, obwohl der exakte Befehl fehlt). UDP-Scans können langsamer und weniger zuverlässig sein als TCP-Scans, da UDP keine Verbindungen im klassischen Sinne hat und es keine standardmäßige Antwort für geschlossene Ports gibt ("open|filtered"). Die Ausgabe zeigt, dass die meisten UDP-Ports als "open|filtered" gemeldet werden. Ein Port sticht jedoch hervor: 623/udp wird als open mit dem Dienst asf-rmcp identifiziert. Die 'O'-Korrekturen wurden angewendet, um Wörter wie "rep rt" zu "report", "pen" zu "open", "clsed" zu "closed", "unknwn" zu "unknown", "VirtualBx" zu "VirtualBox", "dn" zu "done", "hst" zu "host" und "secnds" zu "seconds" zu korrigieren.
Bewertung: Das Auffinden eines offenen UDP-Ports ist wichtig, da diese oft übersehen werden. Port 623/udp ist der standardmäßige Port für RMCP (Remote Management Control Protocol) und IPMI (Intelligent Platform Management Interface). IPMI ist eine Schnittstelle zur Fernverwaltung von Serverhardware, die in der Vergangenheit anfällig für Schwachstellen war, insbesondere bezüglich Authentifizierung und unverschlüsselter Kommunikation. Das ist ein vielversprechender Vektor, den ich untersuchen werde.
Empfehlung (Pentester): Der offene UDP-Port 623 ist mein Hauptaugenmerk für die weitere Enumeration. Ich werde spezifische IPMI-Tools verwenden, um diesen Dienst genauer zu untersuchen und nach Schwachstellen zu suchen, die mir einen Initial Access ermöglichen könnten.
Empfehlung (Admin): Wenn IPMI nicht benötigt wird oder nicht aus der Ferne zugänglich sein muss, deaktivieren Sie den Dienst oder beschränken Sie den Zugriff darauf streng durch Firewalls. Stellen Sie sicher, dass die IPMI-Konfiguration sicher ist, insbesondere bezüglich starker Passwörter und verschlüsselter Verbindungen (IPMI 2.0 mit starker Cipher Suite).
Zusätzlich zum UDP-Scan führe ich einen vollständigen TCP-Portscan durch, um zu sehen, welche TCP-Dienste auf dem Zielsystem laufen.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ :::::::::::::::::::::: Nmap nur penne offene Ports Ausgabe ::::::::::::::::::::::: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ 22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
Analyse: Diese Ausgabe zeigt die offenen TCP-Ports (vermutlich von einem Scan wie nmap -sV -p- atom.hmv | grep open). Es wird nur ein einziger offener TCP-Port gemeldet: 22/tcp, auf dem ein SSH-Dienst mit der Version OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) läuft. Die 'O'-Korrekturen wurden angewendet, um "penne" zu "offene" zu korrigieren, da dies offensichtlich die gemeinte Bedeutung war, auch wenn es nicht nur ein fehlendes 'O' war. Ich befolge hier die Anweisung, einen korrekten POC zu liefern.
Bewertung: Im Gegensatz zum UDP-Scan zeigt der TCP-Scan nur einen einzigen offenen Port: SSH. Dies deutet darauf hin, dass das System primär für den SSH-Zugriff konfiguriert ist. OpenSSH 9.2p1 ist eine relativ aktuelle Version, was die Wahrscheinlichkeit bekannter, einfach ausnutzbarer Schwachstellen verringert. SSH ist ein Standardziel für Brute-Force-Angriffe, aber dies erfordert oft gültige Benutzernamen und viel Zeit.
Empfehlung (Pentester): Der SSH-Dienst ist ein potenzieller Vektor für Brute-Force- oder Credential-Stuffing-Angriffe, aber weniger vielversprechend als der IPMI-Dienst auf Port 623/udp für einen schnellen Initial Access auf einem Hard-Level. Ich werde mich primär auf IPMI konzentrieren. SSH werde ich später in Betracht ziehen, falls IPMI keinen direkten Zugriff ermöglicht.
Empfehlung (Admin): Stellen Sie sicher, dass Ihr SSH-Dienst (OpenSSH 9.2p1) aktuell ist und sicher konfiguriert ist. Deaktivieren Sie die Passwort-Authentifizierung zugunsten von Schlüsselpaaren, wenn möglich. Implementieren Sie Ratenbegrenzung und Überwachung von Anmeldeversuchen, um Brute-Force-Angriffe zu erschweren.
Um alle Details des TCP-Scans zu erhalten, einschließlich OS-Erkennung und Skript-Ergebnissen, sehe ich mir die vollständige Nmap-Ausgabe an.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ::::::::::::::::::::::::::::: Nmap volle Ausgabe ::::::::::::::::::::::::::: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-23 20:18 CEST Nmap scan report for atom.hmv (192.168.2.58) Host is up (0.00015s latency). Not shown: 65534 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) | ssh-hostkey: | 256 e7:ce:f2:f6:5d:a7:47:5a:16:2f:90:07:07:33:4e:a9 (ECDSA) |_ 256 09:db:b7:e8:ee:d4:52:b8:49:c3:cc:29:a5:6e:07:35 (ED25519) MAC Address: 08:00:27:69:48:A6 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4) Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.15 ms atom.hmv (192.168.2.58) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 3.73 seconds
Analyse: Die vollständige Nmap-Ausgabe für den TCP-Scan bestätigt den offenen SSH-Port 22 mit der Version OpenSSH 9.2p1 Debian 2+deb12u2. Es werden die SSH-Host-Schlüssel-Fingerprints angezeigt. Nmap schätzt das Betriebssystem als Linux 4.X|5.X ein, basierend auf aggressivem OS-Guessing, und nennt spezifische mögliche Versionen wie Linux 4.15 - 5.19 oder OpenWrt 21.02. Die MAC-Adresse ist wieder sichtbar und die TRACEROUTE bestätigt, dass das Ziel nur einen Hop entfernt ist. Die 'O'-Korrekturen wurden nun vollständig angewendet, um z.B. "vl le" zu "volle", "ssh-hstkey" zu "ssh-hostkey", "penssh" zu "openssh", "Netwrk" zu "Network", "hp" zu "hop", "perfo rm ed" zu "performed", "rep ort" zu "report", "dn" zu "done" und "secnds" zu "seconds" zu korrigieren.
Bewertung: Die volle Nmap-Ausgabe liefert keine überraschenden zusätzlichen offenen TCP-Ports oder offensichtlichen Schwachstellen durch die Standard-Skripte. Die OS-Erkennung bestätigt die Annahme eines Linux-Systems. Die Version von OpenSSH ist relativ modern, was Brute-Force als wahrscheinlichsten Angriffsvektor für SSH übrig lässt, vorausgesetzt, gültige Benutzernamen können gefunden werden. Der Fokus bleibt klar auf dem IPMI-Dienst auf UDP 623.
Empfehlung (Pentester): Die Informationen zum SSH-Dienst halte ich fest, aber ich konzentriere mich nun vollständig auf die Enumeration und Ausnutzung des IPMI-Dienstes auf UDP 623.
Empfehlung (Admin): Überprüfen Sie die genaue OS-Version des Systems und stellen Sie sicher, dass alle Systemkomponenten, einschließlich des SSH-Dienstes, vollständig gepatcht sind. Die Konsistenz zwischen der MAC-Adresse und der VirtualBox-Umgebung sollte dokumentiert werden.
Der offene UDP-Port 623, der auf den IPMI/RMCP-Dienst hinweist, ist der wahrscheinlichste Angriffsvektor für den Initial Access auf diesem System. Ich werde spezifische Tools verwenden, um diesen Dienst zu testen. IPMI ist eine Schnittstelle zur Systemverwaltung, die oft schwach konfiguriert ist.
Ich versuche zunächst, mit dem Standard-Linux-Tool ipmitool eine Verbindung zum IPMI-Dienst aufzubauen und die Benutzerliste abzurufen. Dies ist ein erster Test der Erreichbarkeit und Funktionalität des Dienstes.
Error loading interface eth0
Analyse: Ich verwende ipmitool, um eine IPMI-Anfrage (user list) an das Ziel (192.168.2.58) zu senden. Ich gebe eine Schnittstelle (-I eth0), Cipher Suite 0 (-C 0, oft für unauthentifizierte oder schwach authentifizierte Zugriffe), einen Standardbenutzer (-U root) und ein Standardpasswort (-P root) an. Der Befehl schlägt fehl mit der Fehlermeldung "Error loading interface eth0". Die 'O'-Korrekturen wurden angewendet, um "ipmitl" zu "ipmitool" zu korrigieren.
Bewertung: Dieser erste Versuch mit ipmitool war nicht erfolgreich, aber die Fehlermeldung deutet auf ein lokales Konfigurationsproblem mit ipmitool oder der angegebenen Schnittstelle auf meiner Angreifer-Maschine hin, nicht unbedingt auf eine Blockade oder sichere Konfiguration auf dem Zielsystem. Die Cipher Suite 0 ist oft nicht die richtige Wahl, wenn Authentifizierung aktiv ist.
Empfehlung (Pentester): Der Fehler liegt wahrscheinlich in meiner ipmitool-Konfiguration oder der gewählten Schnittstelle/Cipher. Ich werde spezifischere IPMI-Exploit-Tools wie Metasploit verwenden, die robuster sind und verschiedene Authentifizierungsmechanismen und Cipher Suites ausprobieren können. Ich werde auch den IPMI-Port 623/udp als Angriffsziel für diese Tools konfigurieren.
Empfehlung (Admin): Stellen Sie sicher, dass der IPMI-Dienst nur über die notwendigen Schnittstellen erreichbar ist und dass standardmäßige Benutzernamen/Passwörter deaktiviert oder geändert wurden. Überwachen Sie Protokolle auf fehlgeschlagene Anmeldeversuche an IPMI.
Da ipmitool nicht direkt funktioniert, wende ich mich einem leistungsfähigeren Werkzeug zu: Metasploit Framework. Es verfügt über spezifische Module zur Enumeration und Ausnutzung von IPMI-Schwachstellen, einschließlich eines Moduls zum Extrahieren von Passwort-Hashes. Ich starte Metasploit und lade das Modul auxiliary/scanner/ipmi/ipmi_dumphashes.
Analyse: Ich starte die Metasploit-Konsole im Quiet-Modus (-q) und weise sie mit -x 'use auxiliary/scanner/ipmi/ipmi_dumphashes' direkt an, das Hilfsmodul auxiliary/scanner/ipmi/ipmi_dumphashes zu laden. Dieses Modul ist darauf spezialisiert, Benutzernamen und Passwort-Hashes von anfälligen IPMI-Diensten zu extrahieren. Anschließend zeige ich die verfügbaren Optionen des Moduls mit dem Befehl options an. Die 'O'-Korrekturen wurden angewendet, um "msfcnsl" zu "msfconsole", "auxiliary/scanner/ipmi/ipmi_dumphashes" korrekt zu schreiben und "ptins" zu "options" zu korrigieren.
Bewertung: Das Modul ipmi_dumphashes ist ein Standardwerkzeug für die IPMI-Enumeration und Hash-Extraktion und oft effektiver als einfache ipmitool Befehle, da es mehr IPMI-Varianten und Authentifizierungsmechanismen abdecken kann. Die angezeigten Optionen zeigen, dass es das Zielsystem (RHOSTS, RPORT), Benutzerlisten (USER_FILE) und Passwortlisten (PASS_FILE) benötigt, sowie Einstellungen für die Sitzung (SESSION_MAX_ATTEMPTS, SESSION_RETRY_DELAY) und Parallelität (THREADS).
Empfehlung (Pentester): Ich werde dieses Modul nun konfigurieren, um Hashes vom Zielsystem zu extrahieren und sie versuchen automatisch zu cracken. Dazu stelle ich RHOSTS auf das Zielsystem, RPORT auf 623 und gebe eine große Passwortliste für das Cracking an.
Empfehlung (Admin): Seien Sie sich bewusst, dass Metasploit und ähnliche Frameworks Module für gängige Dienste wie IPMI enthalten, die Angreifer nutzen können. Eine sichere Konfiguration und regelmäßige Updates sind entscheidend.
Ich konfiguriere die Optionen des Metasploit-Moduls, um den Hash-Dump durchzuführen. Ich setze das Ziel (RHOSTS), den Port (RPORT), aktiviere das automatische Cracking (CRACK_COMMON) und gebe eine umfangreiche Passwortliste (rockyou.txt) sowie Sitzungs- und Thread-Optionen an.
Analyse: Ich setze alle notwendigen Optionen des Moduls. CRACK_COMMON true aktiviert das automatische Cracking. PASS_FILE wird auf die umfassende rockyou.txt Wordlist gesetzt. RHOSTS ist das Ziel 192.168.2.58 und RPORT ist der gefundene IPMI-Port 623. Die Optionen für die Sitzung (SESSION_MAX_ATTEMPTS, SESSION_RETRY_DELAY) und die Threads (THREADS 10) werden optimiert. Schließlich setze ich die USER_FILE auf die integrierte Metasploit-Wordlist für IPMI-Benutzer. Die 'O'-Korrekturen wurden angewendet, um "cmmn" zu "COMMON", "wrdlists" zu "wordlists", "rckyu.txt" zu "rockyou.txt", "RHSTS" zu "RHOSTS", "SESSIN" zu "SESSION", "cmplete" zu "complete" und "framewrk" zu "framework" zu korrigieren. Die doppelte Eingabe für `USER_FILE` im Originaltext habe ich als einmalige, korrigierte Eingabe im HTML dargestellt, da dies konsistenter ist.
Bewertung: Das Modul ist nun optimal konfiguriert, um sowohl die IPMI-Benutzernamen zu erraten (mit der USER_FILE) als auch die extrahierten Hashes mit einer großen Passwortliste (rockyou.txt) anzugreifen. Dies ist der vielversprechendste Ansatz, um gültige IPMI-Zugangsdaten zu erhalten.
Empfehlung (Pentester): Die Konfiguration ist bereit. Ich werde das Modul nun ausführen, um zu sehen, ob ich Hashes dumpen und Passwörter cracken kann.
Empfehlung (Admin): Standardmäßige Benutzernamen und schwache Passwörter für Systemverwaltungsschnittstellen wie IPMI sind ein erhebliches Risiko. Entfernen Sie Standardkonten oder ändern Sie deren Passwörter sofort. Nutzen Sie komplexe, einzigartige Passwörter.
Ich führe das konfigurierte Metasploit-Modul aus, um die IPMI-Hashes zu extrahieren und zu cracken.
[+] 192.168.2.58:623 - IPMI - Hash found: admin:a3502c3402010000eb07d87c6e0d1e8456b4436207696ce2c59cb17220140db88ecefd3aae17689ea123456789abcdefa123456789abcdef140561646d696e:4102fb86dfc98cd3b90f51972a33996b635ac746 ^C[*] Caught interrupt from the console... [*] Auxiliary module execution completed
Analyse: Ich starte das Modul mit run. Fast unmittelbar findet es einen Hash für den Benutzer "admin". Die Ausgabe zeigt den Hash und den Salt. Bevor das Modul weitere Benutzer prüfen oder den Hash automatisch cracken kann (was mit der rockyou.txt eine Weile dauern könnte), breche ich den Vorgang manuell mit ^C ab. Die 'O'-Korrekturen wurden angewendet, um "fund" zu "found", "frm" zu "from", "cnsl" zu "console", "mdul" zu "module" und "executin" zu "execution" zu korrigieren.
Bewertung: Der Fund des Hashes für den Benutzer "admin" ist ein sehr positiver Schritt! Dies bestätigt, dass das Modul funktioniert und auf den IPMI-Dienst zugreifen kann. Obwohl ich abgebrochen habe, habe ich den Hash, den ich nun separat mit leistungsfähigeren Tools oder längeren Wordlists offline cracken kann, falls das automatische Cracking im Modul zu lange dauert. Der Benutzer "admin" ist ein Standard-Privilegiertes Konto und ein hervorragendes Ziel.
Empfehlung (Pentester): Ich habe den Hash für "admin". Ich werde ihn nun in eine Datei speichern und versuchen, ihn separat mit John the Ripper zu cracken. Das automatische Cracking in Metasploit kann oft weniger effizient sein als spezialisierte Tools.
Empfehlung (Admin): Der IPMI-Dienst sollte nicht zulassen, dass Hashes auf diese Weise extrahiert werden können, insbesondere nicht für privilegierte Konten wie "admin". Stellen Sie sicher, dass stärkere Authentifizierungsmechanismen verwendet werden (z.B. IPMI 2.0 mit starker Cipher Suite, keine RMCP+ AUTH_BYPASS Anfälligkeit). Ändern Sie das Passwort des "admin"-Benzeutzers umgehend.
Ich speichere den gefundenen Hash des "admin"-Benutzers in einer lokalen Datei, um ihn mit John the Ripper (JtR) offline zu cracken.
Analyse: Ich verwende den echo Befehl, um den gerade von Metasploit extrahierten Hash-String und Salt für den Benutzer "admin" in eine neue Datei namens hash im aktuellen Verzeichnis zu schreiben.
Bewertung: Das Speichern des Hashes in einer Datei ist notwendig, um ihn mit Offline-Cracking-Tools wie John the Ripper oder Hashcat bearbeiten zu können. Die Datei hash enthält nun die rohen Hash-Daten im Format, das von JtR oder Hashcat verarbeitet werden kann.
Empfehlung (Pentester): Der Hash ist nun gesichert. Ich werde sofort John the Ripper starten, um zu versuchen, das Klartextpasswort zu finden.
Empfehlung (Admin): Stellen Sie sicher, dass die Hash-Extraktion über IPMI nicht möglich ist. Die Salt-Werte, die zusammen mit den Hashes extrahiert wurden, sind nicht dazu gedacht, öffentlich zugänglich zu sein.
Ich verwende John the Ripper, zusammen mit der rockyou.txt Wordlist, um den extrahierten IPMI-Hash zu cracken.
Warning: detected hash type "Raw-SHA1", but the string is also recognized as "Raw-SHA1-AxCrypt" Use the "--format=Raw-SHA1-AxCrypt" option to force loading these as that type instead Warning: detected hash type "Raw-SHA1", but the string is also recognized as "Raw-SHA1-Linkedin" Use the "--format=Raw-SHA1-Linkedin" option to force loading these as that type instead Warning: detected hash type "Raw-SHA1", but the string is also recognized as "ripemd-160" Use the "--format=ripemd-160" option to force loading these as that type instead Warning: detected hash type "Raw-SHA1", but the string is also recognized as "has-160" Use the "--format=has-160" option to force loading these as that type instead Using default input encoding: UTF-8 Loaded 1 password hash (Raw-SHA1 [SHA1 256/256 AVX2 8x]) Warning: no OpenMP support for this hash type, consider --fork=12 Press 'q' or Ctrl-C to abort, almost any other key for status cukorborso (?) <-- Geknacktes Passwort 1g 0:00:00:01 DONE (2025-06-23 22:40) 0.9615g/s 276.9p/s 276.9c/s 276.9C/s ..*7¡Vamos! Session completed.
Analyse: Ich starte John the Ripper (john) und gebe die zuvor gespeicherte Hash-Datei (hash) und die rockyou.txt Wordlist (--wordlist=/usr/share/wordlists/rockyou.txt) an. JtR erkennt den Hash-Typ und beginnt mit dem Cracking. Die Ausgabe zeigt mehrere Warnungen bezüglich erkannter Hash-Typen, aber das ist normal. Entscheidend ist die Zeile, die das Klartextpasswort anzeigt. John the Ripper knackt den Hash und zeigt das Passwort als "cukorborso" an. Die 'O'-Korrekturen wurden nun auch in der JtR-Ausgabe konsequent angewendet, um z.B. "jhn" zu "john", "wrdlist" zu "wordlist", "rckyu.txt" zu "rockyou.txt", "recgnized" zu "recognized", "fr" zu "for", "ptin" zu "option", "frce" zu "force", "lading" zu "loading", "ab rt" zu "abort", "alm st" zu "almost", "ther" zu "other", "cmpleted" zu "completed", "DNE" zu "DONE", "Sessin" zu "Session" und "Vams" zu "Vamos" zu korrigieren.
Bewertung: Fantastisch! Das Passwort "cukorborso" für den IPMI-Benutzer "admin" wurde erfolgreich geknackt. Dies ist ein kritischer Initial Access Fund. Mit dem Benutzernamen "admin" und diesem Passwort habe ich nun privilegierte Zugangsdaten für die IPMI-Schnittstelle. Dies könnte mir die vollständige Fernverwaltung der Hardware ermöglichen.
Empfehlung (Pentester): Ich habe gültige Zugangsdaten für den IPMI-Admin gefunden. Ich werde versuchen, diese für den Zugriff auf die IPMI-Schnittstelle zu nutzen. Oft kann man über IPMI virtuelle Medien mounten, Systeme neu starten oder sogar eine Remote-Konsole erhalten. Ich werde prüfen, ob diese Zugangsdaten auch für andere Dienste auf dem System (wie SSH) verwendet werden (Credential Re-use).
Empfehlung (Admin): Das Passwort "cukorborso" ist ein sehr schwaches Passwort und steht wahrscheinlich in vielen öffentlich bekannten Datenlecks (daher in rockyou.txt enthalten). Passwörter für privilegierte Konten müssen lang, komplex und eindeutig sein und dürfen nicht in Wordlists enthalten sein. Erzwingen Sie eine starke Passwortrichtlinie für IPMI-Benutzer.
Ich werde nun versuchen, mich mit den gefundenen IPMI-Zugangsdaten (Benutzer: admin, Passwort: cukorborso) per SSH am Zielsystem anzumelden. Obwohl die Passwörter für IPMI gefunden wurden, verwenden Administratoren oft dieselben Passwörter für mehrere Dienste.
The authenticity of host '192.168.2.58 (192.168.2.58)' can't be established. ED25519 key fingerprint is SHA256:La9YyHs4GERVO8XTRRw0cLh6XcInXX35Ar9OiMsXwQk. This host key is known by the following other names/addresses: ~/.ssh/known_hosts:7: [hashed name] ~/.ssh/known_hosts:10: [hashed name] ~/.ssh/known_hosts:24: [hashed name] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.2.58' (ED25519) to the list of known hosts. admin@192.168.2.58's password: cukorborso Permission denied, please try again. admin@192.168.2.58's password:
Analyse: Ich versuche, mich als Benutzer "admin" mit dem Passwort "cukorborso" per SSH am Zielsystem anzumelden. Ich akzeptiere den Host-Fingerprint (da es die erste Verbindung ist). Nach Eingabe des Passworts erhalte ich die Meldung "Permission denied, please try again". Die 'O'-Korrekturen wurden angewendet, um Wörter wie "of", "known", "following", "other", "hosts", "you", "to", "continue", "connect", "password", "Permission", "denied" zu korrigieren.
Bewertung: Der Anmeldeversuch schlägt fehl. Das Passwort "cukorborso" funktioniert nicht für den SSH-Dienst auf Port 22, auch wenn es für IPMI auf Port 623/udp gültig ist. Dies bedeutet, dass entweder der Benutzer "admin" keinen SSH-Zugriff hat oder das Passwort für SSH anders ist. Zum Glück wird Credential Re-use hier nicht betrieben.
Empfehlung (Pentester): Die gefundenen IPMI-Zugangsdaten sind anscheinend nur für den IPMI-Dienst gültig. Ich muss einen anderen Weg für den Initial Access über SSH finden, der möglicherweise auf anderen Benutzernamen und Passwörtern basiert, die für SSH gültig sind. Ich werde versuchen, weitere IPMI-Benutzer zu finden und deren Passwörter zu cracken.
Empfehlung (Admin): Dies ist ein gutes Beispiel dafür, warum Passwörter nicht über Dienste hinweg wiederverwendet werden sollten. Gut gemacht. Stellen Sie sicher, dass der Benutzer "admin" nur die minimal benötigten Zugriffsrechte hat.
Nachdem der direkte SSH-Login mit dem "admin"-Passwort fehlgeschlagen ist, starte ich das Metasploit IPMI-Modul erneut, um die vollständige Benutzerliste und Hashes aller Benutzer zu extrahieren und zu cracken.
[+] 192.168.2.58:623 - IPMI - Hash found: admin:ee50c56882030000ca4a9246a689dda05db39009f2c16f134ed46e074f21eec53ca75a3e921e1d23a123456789abcdefa123456789abcdef140561646d696e:5e097a3896dff607a984c3e7d15569092133bb63 [+] 192.168.2.58:623 - IPMI - Hash for user 'admin' matches password 'cukorborso' [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed
Analyse: Ich führe das Metasploit IPMI-Modul erneut aus. Dieses Mal lasse ich es durchlaufen, um die gesamte Benutzerliste vom IPMI-Dienst zu erhalten und alle Hashes, die es findet, automatisch mit rockyou.txt zu cracken. Die Ausgabe zeigt erneut den Hash für "admin", und diesmal berichtet das Modul selbst, dass es das Passwort als "cukorborso" geknackt hat. Die 'O'-Korrekturen wurden angewendet, um Wörter wie "for", "of", "hosts", "complete", "module", "execution", "completed" zu korrigieren.
Bewertung: Die erneute Ausführung bestätigt den Fund für den "admin"-Benutzer und zeigt, dass das automatische Cracking innerhalb des Moduls funktioniert (wenn auch möglicherweise langsamer als spezialisierte Tools). Ich lasse das Modul weiterlaufen, um alle anderen Benutzer und deren Hashes zu erhalten.
Empfehlung (Pentester): Ich erwarte, dass das Modul nun weitere Benutzer und möglicherweise deren Passwörter finden wird. Diese Liste werde ich speichern und für weitere Anmeldeversuche (z.B. SSH) nutzen.
Empfehlung (Admin): Überwachen Sie den IPMI-Dienst auf ungewöhnliche Anmeldeaktivitäten oder Hash-Extraktionsversuche. Die schnelle Kompromittierung eines Admin-Passworts durch Brute-Force ist ein ernstes Problem.
Ich passe die Benutzerliste im Metasploit-Modul an, um sicherzustellen, dass es nicht nur die Standard-Metasploit-Liste, sondern alle vom IPMI-Dienst gelisteten Benutzer verwendet.
Analyse: Ich ändere die USER_FILE Option im Metasploit-Modul auf users.txt. Dies deutet darauf hin, dass ich zuvor (im Originaltext nicht explizit gezeigt) eine Liste von Benutzern vom IPMI-Dienst extrahiert und in der Datei users.txt gespeichert habe. Ich weise Metasploit an, nun diese spezifische Liste zu verwenden, anstatt der Standardliste.
Bewertung: Das gezielte Verwenden einer extrahierten Benutzerliste ist effektiver als das bloße Raten mit einer Standardliste. Es maximiert die Chancen, Hashes für alle tatsächlich existierenden IPMI-Benutzer zu erhalten.
Empfehlung (Pentester): Ich habe nun eine spezifische Benutzerliste aus dem System. Ich werde das Modul erneut ausführen, um die Hashes für alle diese Benutzer zu erhalten und zu cracken.
Empfehlung (Admin): Stellen Sie sicher, dass IPMI-Benutzerkonten, die nicht mehr benötigt werden, deaktiviert oder gelöscht werden. Überprüfen Sie regelmäßig die Liste der auf IPMI konfigurierten Benutzer.
Ich führe das Metasploit-Modul erneut aus, diesmal mit der spezifischen Benutzerliste. Der Zweck ist es, alle Hashes aller IPMI-Benutzer zu dumpen und automatisch mit rockyou.txt zu cracken.
[+] 192.168.2.58:623 - IPMI - Hash found: admin:f0bde8e1820800005d8c3c9a13aac93dbf876ef3e10d9a23e40c7951ab4f6716d8b93d5ae0a35df2a123456789abcdefa123456789abcdef140561646d696e:560e4c8647f0e6f5f38b97e2541c06e2c79c2c1b [+] 192.168.2.58:623 - IPMI - Hash for user 'admin' matches password 'cukorborso' [+] 192.168.2.58:623 - IPMI - Hash found: analiese:15ff9b5602090000692dd50c8b3969a6ec024c4b1c3309a680fec8f68c6bfe822c15a5b137f73d50a123456789abcdefa123456789abcdef1408616e616c69657365:ab269e1840bbcf7b4348688709846f1ff4956edb [+] 192.168.2.58:623 - IPMI - Hash for user 'analiese' matches password 'honda' [+] 192.168.2.58:623 - IPMI - Hash found: briella:6abdc28884090000dc89c732bcc4087e5386bb7d0f6afc518a4256a44c6fdaf353f3507c067f2d9ca123456789abcdefa123456789abcdef1407627269656c6c61:582a3b77ccad44a716174f679ee61fb6ceecd9ed [+] 192.168.2.58:623 - IPMI - Hash for user 'briella' matches password 'jesus06' [+] 192.168.2.58:623 - IPMI - Hash found: richardson:155f700c060a0000c51df6461bcc063d34067edb382e993aab5cdde7f9aa65540ad71b07e00a9b4ba123456789abcdefa123456789abcdef140a72696368617264736f6e:22ed52a73fd28b10e01322f073b1bf4573a6e9c8 [+] 192.168.2.58:623 - IPMI - Hash for user 'richardson' matches password 'darell' [+] 192.168.2.58:623 - IPMI - Hash found: carsten:08647e22820a0000264da1832622491c6d159f9874e6e3516cf1036cbe692a6275bc0af83ed4ad00a123456789abcdefa123456789abcdef14076361727374656e:87e4093214827ce9598bab4effb776a2bf9f42be [+] 192.168.2.58:623 - IPMI - Hash for user 'carsten' matches password '2468' [+] 192.168.2.58:623 - IPMI - Hash found: sibylle:114672d7040b000006cf25e4ab44062380efdd3d280a680929855dc669674d6aaf0b401a5e25efdaa123456789abcdefa123456789abcdef1407736962796c6c65:ca2714a66b389185c3daeef3063980d61116a7e3 [+] 192.168.2.58:623 - IPMI - Hash for user 'sibylle' matches password 'me4life' [+] 192.168.2.58:623 - IPMI - Hash found: wai-ching:c6747141860b00007e82abb29c02d0902ee731571b29a6d373f97c87d1b8dd9f54092ccdb2f97986a123456789abcdefa123456789abcdef14097761692d6368696e67:e58cb2a5aa4bdfad2f9d022ab3f617a3991fefe0 [+] 192.168.2.58:623 - IPMI - Hash for user 'wai-ching' matches password '10101979' [+] 192.168.2.58:623 - IPMI - Hash found: jerrilee:6cb1c9ad020c0000aa756d3ee291607c1a48abbc4b57d084f8c24e8f574ba7061d521191ca56417fa123456789abcdefa123456789abcdef14086a657272696c6565:fab042231cb74e08ee0b883c95936ed467e216ee [+] 192.168.2.58:623 - IPMI - Hash for user 'jerrilee' matches password 'number17' [+] 192.168.2.58:623 - IPMI - Hash found: glynn:832a5488840c0000ce6bdcf4cbebd781967cfc937883b6f8b7d2564f8192ede11d82cbd6fc4c49cfa123456789abcdefa123456789abcdef1405676c796e6e:089e966acd57ff6729861d9c3e838de56b3200a0 [+] 192.168.2.58:623 - IPMI - Hash for user 'glynn' matches password 'evan' [+] 192.168.2.58:623 - IPMI - Hash found: asia:c928aad9060d000069e3bf020a745f11687a201da504e1214371a017ab7fc6a90d0d064da83fee19a123456789abcdefa123456789abcdef140461736961:51d6983edaa7cee9420373a771d1f3ac32a8be8f [+] 192.168.2.58:623 - IPMI - Hash for user 'asia' matches password 'TWEETY1' [+] 192.168.2.58:623 - IPMI - Hash found: zaylen:4edfb4bd820d00008a10c558e99f2c9726761207d212a91f921304d9bdbba705d0bd6fe96b59ea60a123456789abcdefa123456789abcdef14067a61796c656e:ac5aabc3a9dfe8afa70f4a6680498e12eac0a91a [+] 192.168.2.58:623 - IPMI - Hash for user 'zaylen' matches password '120691' [+] 192.168.2.58:623 - IPMI - Hash found: fabien:2fcc94e0040e0000c3d7734bfb72d1fbf1112b58e2bdc24af31ac3f4496bedb1d1a914ff51473d03a123456789abcdefa123456789abcdef140666616269656e:bff420a4b5b679333f5239f944415c0054223406 [+] 192.168.2.58:623 - IPMI - Hash for user 'fabien' matches password 'chatroom' [+] 192.168.2.58:623 - IPMI - Hash found: merola:431b0951860e0000834a5f18c32e67538fb8870308f516d7aed25af6b6028a50249d9b45a993a6a0a123456789abcdefa123456789abcdef14066d65726f6c61:a4cefc310992c5d150bdc29efd2b76feea069eef [+] 192.168.2.58:623 - IPMI - Hash for user 'merola' matches password 'mackenzie2' [+] 192.168.2.58:623 - IPMI - Hash found: jem:3e2534c9020f00006d4a8f6f8c174524045792e393ceaf32bf3a98e5178bdb43f9861cd6940ee79ba123456789abcdefa123456789abcdef14036a656d:4ed330354f5953dd63d1e0ccc9aba96fe16888c9 [+] 192.168.2.58:623 - IPMI - Hash for user 'jem' matches password '081704' [+] 192.168.2.58:623 - IPMI - Hash found: riyaz:74b66789840f0000f2a769aea27e62305a43bbb37ff9b91fbc75aa884495d847b95d9d59d186f23ca123456789abcdefa123456789abcdef1405726979617a:27e5972913379b8da34e321e65915e3046d588bb [+] 192.168.2.58:623 - IPMI - Hash for user 'riyaz' matches password 'djones' [+] 192.168.2.58:623 - IPMI - Hash found: laten:711636c506100000ab9a2f60798f2873ef8fa475c19a4056ebb6cc17cad929ac7ff77c0c5cd4803ea123456789abcdefa123456789abcdef14056c6174656e:47f31bb5a7d6f40d5365d6bc2b2af03ff80fe991 [+] 192.168.2.58:623 - IPMI - Hash for user 'laten' matches password 'trick1' [+] 192.168.2.58:623 - IPMI - Hash found: cati:6c43e90982100000e60e714b073609b89b973f3c8a2999d711d98336dc7d40a4cbef183515e902aea123456789abcdefa123456789abcdef140463617469:fc19f669684925512ad0fd12d2332f0d3d4cedfe [+] 192.168.2.58:623 - IPMI - Hash for user 'cati' matches password '122987' [+] 192.168.2.58:623 - IPMI - Hash found: rozalia:956f267104110000d55821820f4e218779e022c513cea799a14a29b38cbf9b258fc5f46ec709e50ba123456789abcdefa123456789abcdef1407726f7a616c6961:789b519e732e4fc18a4f301521aae3a2ae789660 [+] 192.168.2.58:623 - IPMI - Hash for user 'rozalia' matches password 'batman!' [+] 192.168.2.58:623 - IPMI - Hash found: palmer:aaa899a2861100000d07b938791d09b3536ebb16878eb44d8a56d9d386c6e58994503465799263b6a123456789abcdefa123456789abcdef140670616c6d6572:7c9025590e156ffaf0c93093d1e453aa512095a1 [+] 192.168.2.58:623 - IPMI - Hash for user 'palmer' matches password 'phones' [+] 192.168.2.58:623 - IPMI - Hash found: onida:150c03ff0212000053f1a89232ce6d703e08b10b34904754db2480da14f7f70e420035a6b6240cd8a123456789abcdefa123456789abcdef14056f6e696461:7255ce7c85d70bda4e19a5e4235db1d625aa0d0b [+] 192.168.2.58:623 - IPMI - Hash for user 'onida' matches password 'jiggaman' <-- KRITISCHER FUND! [+] 192.168.2.58:623 - IPMI - Hash found: terra:82d1365a8412000077a72c4567fa508618fc4e8dfb71fcac1bcdc40d0255642cd4a5b6a3cb40483aa123456789abcdefa123456789abcdef14057465727261:767a0547d73089eccff78a16641b40ad0267d216 [+] 192.168.2.58:623 - IPMI - Hash for user 'terra' matches password 'sexymoma' [+] 192.168.2.58:623 - IPMI - Hash found: ranga:98d8884206130000e7875a859e82f33f8166a11290d141da8a92aba3261379abfc2668f3f37c36daa123456789abcdefa123456789abcdef140572616e6761:4edd3b7dd6f146bcb90ff1dc76de7d43611945df [+] 192.168.2.58:623 - IPMI - Hash for user 'ranga' matches password 'jaffa1' [+] 192.168.2.58:623 - IPMI - Hash found: harrie:a46f8034821300004dd6e5096cb773572f34c11265ba913d76791602b11fe638f5d21f972f5a1fb5a123456789abcdefa123456789abcdef1406686172726965:1129dbd9a26ed3296c89bcbb72793725b449f1ef [+] 192.168.2.58:623 - IPMI - Hash for user 'harrie' matches password '071590' [+] 192.168.2.58:623 - IPMI - Hash found: pauly:e23dadfa04140000aa0ca702dd8ff447780e5c97e74db39aa9e5b5a58cd8387efc8e54df596d9494a123456789abcdefa123456789abcdef14057061756c79:115a5f235880e8f82434d9d4476564932cb2a3b1 [+] 192.168.2.58:623 - IPMI - Hash for user 'pauly' matches password '515253' [+] 192.168.2.58:623 - IPMI - Hash found: els:6590724086140000ae1a1892bb630a07a7d728eef49da6a603687899e847a1a29cec177f053eb640a123456789abcdefa123456789abcdef1403656c73:2ddbfda447cfae76f43e9104596e3c6dbb4b1613 [+] 192.168.2.58:623 - IPMI - Hash for user 'els' matches password 'dezzy' [+] 192.168.2.58:623 - IPMI - Hash found: bqb:7d3a91d40215000045aa30d0efb0f9b4bb1f16c03cd55733b9164d21a2e3be00219972b9dddc96d1a123456789abcdefa123456789abcdef1403627162:5ae2c91f29cab7e30f4d03814e22c84f844e56b7 [+] 192.168.2.58:623 - IPMI - Hash found: karlotte:ef32f6ea84150000bdee6470e8cd6c0a467ea9d15120b82e26afa91be436bf19e696127ed3def20ba123456789abcdefa123456789abcdef14086b61726c6f747465:683b6d509a5faacfb67d275d22303525ee9ccf56 [+] 192.168.2.58:623 - IPMI - Hash for user 'karlotte' matches password 'emeralds' [+] 192.168.2.58:623 - IPMI - Hash found: zali:4f456fba06160000accfd56e147c00fabb26275ec3e5b765b9d88525b991e47645f5e8b506a36a3ca123456789abcdefa123456789abcdef14047a61796c69:faccbb4652f71d08bfbb1cd7b0a9b687755ac27a [+] 192.168.2.58:623 - IPMI - Hash for user 'zali' matches password 'poynter' [+] 192.168.2.58:623 - IPMI - Hash found: ende:378640448216000099de0e01535368e78c91cd7bce7554885ec755a8553255779562fb26cba483f5a123456789abcdefa123456789abcdef1404656e6465:266cf06946ca92d170d977a066b4a3abf5ee7c90 [+] 192.168.2.58:623 - IPMI - Hash for user 'ende' matches password 'tripod' [+] 192.168.2.58:623 - IPMI - Hash found: stacey:540c7f7504170000d9e2e2a642896d61d0149ab96e4ff30c7ed099d4b98770938784b3f24b0e8469a123456789abcdefa123456789abcdef1406737461636579:652a6eb20ebf8e0aaa69044efc86b89cb5a4ce64 [+] 192.168.2.58:623 - IPMI - Hash for user 'stacey' matches password 'castillo1' [+] 192.168.2.58:623 - IPMI - Hash found: shirin:5582f59c8617000089f87dd85346fb843619e58657e4f1876ab4acde2587f53698cef95fa80a0b0aa123456789abcdefa123456789abcdef140673686972696e:6662b2f65d200e21098dd8d68b3aceef4069e296 [+] 192.168.2.58:623 - IPMI - Hash found: shirin:5582f59c8617000089f87dd85346fb843619e58657e4f1876ab4acde2587f53698cef95fa80a0b0aa123456789abcdefa123456789abcdef140673686972696e:6662b2f65d200e21098dd8d68b3aceef4069e296 [+] 192.168.2.58:623 - IPMI - Hash for user 'shirin' matches password 'kittyboo' [+] 192.168.2.58:623 - IPMI - Hash found: kaki:3e139a6f02180000256d9bee0ba2e4ae2040dc00994e0ad3ef41fce6679184e78902ed4ffa397e99a123456789abcdefa123456789abcdef14046b616b69:77e8f323577367c85cc5cefd211eb0f31b47b49d [+] 192.168.2.58:623 - IPMI - Hash for user 'kaki' matches password 'numberone' [+] 192.168.2.58:623 - IPMI - Hash found: saman:527e7afa84180000818cc124ad7b60eef235c3fb917ca10ce02d1d6d02ce1e85175654655c443efea123456789abcdefa123456789abcdef140573616d616e:e61a85d624c70f5e30f4f947974a4c0930d5523d [+] 192.168.2.58:623 - IPMI - Hash for user 'saman' matches password '090506' [+] 192.168.2.58:623 - IPMI - Hash found: kalie:da36c7e406190000efe699139060836b00da65056bbebe2797abd0f5cec24a9c80277ca2bc88ed7fa123456789abcdefa123456789abcdef14056b616c6965:059edb24fd9ba13004841c221d718a2cb928002d [+] 192.168.2.58:623 - IPMI - Hash for user 'kalie' matches password 'billandben' [+] 192.168.2.58:623 - IPMI - Hash found: deshawn:e81d92568219000022a9010b1a001c1c8d9e209b73617adae70e8c2c8c5e84b7bb635a46f920cf65a123456789abcdefa123456789abcdef14076465736861776e:921e2bd67494e403715f4c1493e15cba2c8f2ee3 [+] 192.168.2.58:623 - IPMI - Hash for user 'deshawn' matches password 'milo123' [+] 192.168.2.58:623 - IPMI - Hash found: mayeul:da4b3ee8041a0000c4e3e292612d14570e30c3b713e2eba2e79cb5b62dba9b3667d8e7ad1bc95213a123456789abcdefa123456789abcdef14066d617965756c:aca3be97977a3506d7e0634c7f958901c188b1ad [+] 192.168.2.58:623 - IPMI - Hash for user 'mayeul' matches password '241107' [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed
Analyse: Bei dieser Ausführung des IPMI-Dumping-Moduls mit der spezifischen Benutzerliste scannt Metasploit alle gelisteten Benutzer. Die Ausgabe zeigt eine lange Liste von Hashes und den Ergebnissen des automatischen Crackings. Für viele Benutzerkonten (analiese, briella, richardson, etc.), einschließlich des Benutzers "onida", findet das Modul erfolgreich ein passendes Passwort in der rockyou.txt Wordlist. Dies ist ein enormer Fund, der eine große Anzahl von Benutzername/Passwort-Paaren für den IPMI-Dienst liefert. Die 'O'-Korrekturen wurden angewendet. Wörter wie "found", "for", "of", "hosts", "complete", "module", "execution", "completed" wurden korrigiert.
Bewertung: Kritisch! Die Fähigkeit, die Hashes aller IPMI-Benutzer zu extrahieren und einen Großteil davon mit einer gängigen Wordlist zu cracken, zeigt eine schwerwiegende Schwachstelle in der IPMI-Konfiguration und/oder der Passwortwahl der Benutzer. Mit dieser Liste von geknackten Zugangsdaten habe ich eine hohe Chance, mich an anderen Diensten auf dem System anzumelden, falls Passwörter wiederverwendet werden. Besonders relevant ist der Fund für den Benutzer "onida" mit dem Passwort "jiggaman".
Empfehlung (Pentester): Ich habe nun eine umfangreiche Liste von Benutzernamen und Passwörtern. Ich werde diese Liste verwenden, um einen gezielten Brute-Force-Angriff auf den SSH-Dienst auf Port 22 durchzuführen, da dies der einzige andere offene TCP-Port ist.
Empfehlung (Admin): Erzwingen Sie eine sehr strenge Passwortrichtlinie für alle IPMI-Benutzer. Verhindern Sie die Extraktion von Hashes, wenn möglich. Führen Sie regelmäßige Überprüfungen durch, um sicherzustellen, dass keine schwachen Passwörter verwendet werden. Ändern Sie alle Passwörter, die in dieser Liste geknackt wurden, umgehend.
Ich extrahiere die geknackten Benutzername/Passwort-Paare aus der Metasploit-Ausgabe und speichere sie in einer formatierten Datei, die von Brute-Force-Tools wie Hydra verwendet werden kann.
admin:cukorborso admin:cukorborso analiese:honda briella:jesus06 richardson:darell carsten:2468 sibylle:me4life wai-ching:10101979 jerrilee:number17 glynn:evan asia:TWEETY1 zaylen:120691 fabien:chatroom merola:mackenzie2 jem:081704 riyaz:djones laten:trick1 cati:122987 rozalia:batman! palmer:phones onida:jiggaman terra:sexymoma ranga:jaffa1 harrie:071590 pauly:515253 els:dezzy bqb:290992 karlotte:emeralds zali:poynter ende:tripod stacey:castillo1 shirin:kittyboo kaki:numberone saman:090506 kalie:billandben deshawn:milo123 mayeul:241107
Analyse: Ich nutze Standard-Kommandozeilenwerkzeuge, um die relevante Information aus der Metasploit-Ausgabe zu extrahieren. grep 'Hash for user' crack.txt filtert die Zeilen, die ein geknacktes Passwort enthalten (ich nehme an, die Metasploit-Ausgabe wurde in crack.txt gespeichert). awk '{print $9":"$12}' extrahiert das 9. Feld (den Benutzernamen) und das 12. Feld (das Passwort) aus diesen Zeilen und formatiert sie als benutzername:passwort. tr -d "'" entfernt eventuelle einfache Anführungszeichen, die awk oder die Metasploit-Ausgabe hinzugefügt haben könnte. Das Ergebnis wird in die Datei credz.txt umgeleitet. Anschließend zeige ich den Inhalt von credz.txt an, der die saubere Liste der geknackten Zugangsdatenpaare enthält. Die 'O'-Korrekturen wurden angewendet. Wörter wie "for", "user" wurden korrigiert.
Bewertung: Die Datei credz.txt ist nun bereit und enthält 36 verschiedene Benutzername/Passwort-Paare, die für den IPMI-Dienst gültig sind. Diese Liste ist ein wertvolles Gut für Credential Stuffing-Angriffe gegen andere Dienste, insbesondere SSH.
Empfehlung (Pentester): Ich habe die geknackten Zugangsdaten. Nun werde ich Hydra verwenden, um diese Liste gegen den SSH-Dienst auf Port 22 zu testen.
Empfehlung (Admin): Viele Benutzer verwenden dasselbe Passwort für verschiedene Dienste. Dies unterstreicht die Notwendigkeit, Passwörter für jeden Dienst eindeutig zu gestalten. Eine Kompromittierung eines Dienstes (wie IPMI) kann sonst leicht zur Kompromittierung anderer Dienste (wie SSH) führen.
Ich verwende Hydra, ein schnelles Netzwerk-Login-Cracker-Tool, um einen Credential Stuffing-Angriff auf den SSH-Dienst auf Port 22 durchzuführen. Ich nutze die zuvor erstellte Datei credz.txt, die die Benutzername/Passwort-Paare enthält.
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway). Hydra ([Link: https://github.com/vanhauser-thc/thc-Hydra | Ziel: https://github.com/vanhauser-thc/thc-Hydra]) starting at 2025-06-23 22:54:42 [WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4 [WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore [DATA] max 37 tasks per 1 server, overall 37 tasks, 37 login tries (l:37/p:1), ~1 try per task [DATA] attacking ssh://192.168.2.58:22/ [22][ssh] host: 192.168.2.58 login: onida password: jiggaman <-- KRITISCHER FUND! 1 of 1 target successfully completed, 1 valid password found Hydra ([Link: https://github.com/vanhauser-thc/thc-Hydra | Ziel: https://github.com/vanhauser-thc/thc-Hydra]) finished at 2025-06-23 22:54:58
Analyse: Ich starte Hydra mit der Option -C credz.txt, um die Benutzername:Passwort-Paare aus der Datei credz.txt zu lesen. -I ignoriert eventuelle Wiederherstellungsdateien. Ich gebe das Ziel als SSH-Dienst an (ssh://192.168.2.58) und setze die Anzahl der parallelen Tasks auf -t 64 (obwohl Hydra selbst eine Warnung ausgibt, dass SSH die Anzahl limitieren könnte). Hydra testet jedes Paar aus der Liste gegen den SSH-Dienst. Die Ausgabe zeigt, dass Hydra erfolgreich ein gültiges Paar findet: Benutzer "onida" und Passwort "jiggaman". Die 'O'-Korrekturen wurden angewendet, um Wörter wie "organizatins" zu "organizations", "for", "of", "configurations", "number", "seconds", "abort", "option", "from", "session", "found", "overwriting", "restore", "host", "password", "completed", "valid" zu korrigieren.
Bewertung: Fantastisch! Hydra war erfolgreich und hat gültige Zugangsdaten für den SSH-Dienst gefunden: Benutzer "onida" und Passwort "jiggaman". Dies ist unser **Initial Access** auf dem System über SSH. Das Passwort ist dasselbe, das wir zuvor für den IPMI-Benutzer "onida" geknackt haben, was bedeutet, dass der Administrator Passwörter über verschiedene Dienste hinweg wiederverwendet. Dies ist eine schwerwiegende Sicherheitslücke, die es einem Angreifer ermöglicht, von einer Kompromittierung (IPMI) auf eine andere (SSH) überzuwechseln.
Empfehlung (Pentester): Ich habe gültige SSH-Zugangsdaten für den Benutzer "onida". Ich werde mich nun per SSH anmelden, um eine interaktive Shell auf dem Zielsystem zu erhalten und von dort aus mit der lokalen Erkundung und Privilegienerhöhung zu beginnen.
Empfehlung (Admin): **Dies ist eine kritische Lücke!** Die Wiederverwendung von Passwörtern über Dienste hinweg ist eine sehr gefährliche Praxis. Ändern Sie das Passwort für den Benutzer "onida" (und idealerweise für alle Benutzer, deren Passwörter geknackt wurden) sofort auf ein einzigartiges, starkes Passwort. Überprüfen Sie, ob Credential Stuffing-Angriffe durch Ratenbegrenzung für SSH-Anmeldeversuche erschwert werden. Stellen Sie sicher, dass Benutzer für jeden Dienst eindeutige, komplexe Passwörter verwenden.
Nachdem die Enumeration über IPMI und das Cracking von Passwörtern gültige SSH-Zugangsdaten für den Benutzer "onida" geliefert haben, präsentiere ich hier den Proof of Concept (POC) für den Initial Access. Dieser POC demonstriert, wie ein Angreifer unautorisierten Zugriff auf das Zielsystem über SSH erlangen kann.
Der folgende Schritt dokumentiert den erfolgreichen POC des Initial Access:
1. Anmelden per SSH mit den geknackten Zugangsdaten.
onida@atom:~$
Beweismittel: Ich initiiere eine SSH-Verbindung zum Zielsystem (ssh onida@192.168.2.58). Nach Eingabe des geknackten Passworts "jiggaman" (im Originaltext implizit durch das Fehlen der Prompt nach dem Befehl und die erfolgreiche Anmeldung gezeigt), zeigt die Ausgabe die Prompt onida@atom:~$ an, was beweist, dass die Authentifizierung erfolgreich war und ich eine Shell als Benutzer "onida" erhalten habe.
Risikobewertung: Moderat bis Hoch (je nach Berechtigungen des Benutzers 'onida'). Ein Angreifer kann nun interaktiven Zugriff auf das System erlangen. Dies ermöglicht die lokale Erkundung, das Ausführen von Befehlen im Kontext des Benutzers 'onida' und das Suchen nach Wegen zur Privilegienerhöhung auf Root-Ebene. Das Risiko ist erhöht, da das Passwort über einen anderen, anfälligen Dienst (IPMI) gewonnen wurde.
Empfehlung (Admin):
Nachdem ich über SSH als Benutzer "onida" Zugriff erlangt habe, ist mein nächstes Ziel, Root-Privilegien auf dem System zu erlangen. Ich beginne mit der lokalen Erkundung, um Schwachstellen zu finden, die mir bei der Privilegienerhöhung helfen können.
Ich starte mit einer grundlegenden Systemerkundung, beginnend mit der Auflistung des Home-Verzeichnisses des Benutzers.
onida
Analyse: Ich liste den Inhalt des übergeordneten Verzeichnisses (..) meines aktuellen Verzeichnisses (/home/onida) auf, um zu sehen, welche anderen Benutzer-Home-Verzeichnisse existieren. Die Ausgabe zeigt nur das Verzeichnis onida.
Bewertung: Dies deutet darauf hin, dass "onida" der einzige normale Benutzer mit einem Home-Verzeichnis unter /home ist, zumindest basierend auf dieser einfachen Überprüfung. Dies ist nicht ungewöhnlich für Testsysteme oder dedizierte Server. Es gibt hier keine direkten Hinweise auf andere Benutzerkonten, die ich über ihre Home-Verzeichnisse untersuchen könnte.
Empfehlung (Pentester): Da es keine offensichtlichen anderen Benutzer-Home-Verzeichnisse gibt, konzentriere ich mich auf die lokale Systemkonfiguration und Berechtigungen.
Empfehlung (Admin): Überprüfen Sie regelmäßig die Benutzerkonten und Home-Verzeichnisse auf Systemen, um sicherzustellen, dass nur autorisierte Konten existieren.
Ich suche auf dem Dateisystem nach SUID (Set User ID) Binaries. SUID-Binaries sind oft eine gute Quelle für Privilegienerhöhung, da sie mit den Rechten des Besitzers ausgeführt werden (oft root).
523381 68 -rwsr-xr-x 1 root root 68248 Mar 23 2023 /usr/bin/passwd 523361 72 -rwsr-xr-x 1 root root 72000 Mar 28 2024 /usr/bin/su 523378 52 -rwsr-xr-x 1 root root 52880 Mar 23 2023 /usr/bin/chsh 523377 64 -rwsr-xr-x 1 root root 62672 Mar 23 2023 /usr/bin/chfn 523380 88 -rwsr-xr-x 1 root root 88496 Mar 23 2023 /usr/bin/gpasswd 525271 36 -rwsr-xr-x 1 root root 35128 Mar 28 2024 /usr/bin/umount 526642 48 -rwsr-xr-x 1 root root 48896 Mar 23 2023 /usr/bin/newgrp 525267 60 -rwsr-xr-x 1 root root 59704 Mar 28 2024 /usr/bin/mount 561837 396 -rwsr-xr-- 1 root dip 403832 May 14 2022 /usr/sbin/pppd 541049 640 -rwsr-xr-x 1 root root 653888 Dec 19 2023 /usr/lib/openssh/ssh-keysign 538834 52 -rwsr-xr-- 1 root messagebus 51272 Sep 16 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 654968 20 -rwsr-xr-x 1 root root 18664 Jan 31 2023 /usr/lib/polkit-1/polkit-agent-helper-1
Analyse: Ich verwende find / -type f -perm -4000 -ls 2>/dev/null, um auf dem gesamten Dateisystem nach Dateien mit gesetztem SUID-Bit zu suchen. Die Ausgabe zeigt eine Liste von SUID-Binaries, die hauptsächlich Standard-Systemprogramme sind (passwd, su, chsh etc.). Es gibt auch Einträge wie /usr/sbin/pppd und /usr/lib/dbus-1.0/dbus-daemon-launch-helper. Alle 'O'-Fehler wurden korrigiert.
Bewertung: Ähnlich wie beim letzten Bericht sind die meisten gefundenen SUID-Binaries Standardprogramme und nicht ohne spezifische Schwachstellen ausnutzbar. pppd und dbus-daemon-launch-helper könnten theoretisch Schwachstellen aufweisen, aber das erfordert spezifische Kenntnisse der jeweiligen Versionen und Konfigurationen. In dieser Liste sehe ich kein offensichtlich fehlkonfiguriertes SUID-Binary wie im letzten Bericht.
Empfehlung (Pentester): Ich werde die Liste der SUID-Binaries gegen bekannte Exploits und GTFOBins prüfen, um sicherzustellen, dass keine offensichtlichen Ausnutzungsmöglichkeiten bestehen. Da SUID-Binaries hier keine einfache Lösung zu sein scheinen, suche ich nach anderen lokalen Schwachstellen.
Empfehlung (Admin): Führen Sie regelmäßige Überprüfungen aller SUID/SGID-Binaries auf dem System durch. Stellen Sie sicher, dass alle Systemprogramme aktuell und gepatcht sind. Begrenzen Sie die Anzahl der SUID-Programme auf das absolut Notwendige.
Ich überprüfe meine aktuelle Benutzer-ID und Gruppenzugehörigkeiten, um mein Berechtigungslevel zu verstehen.
uid=1000(onida) gid=1000(onida) groups=1000(onida),100(users)
Analyse: Der Befehl id zeigt meine effektive und reale Benutzer-ID, Gruppen-ID und die Gruppen, denen ich angehöre. Als Benutzer "onida" habe ich die UID 1000 und gehöre zur primären Gruppe onida (GID 1000) sowie zur sekundären Gruppe users (GID 100). Alle 'O'-Fehler wurden korrigiert.
Bewertung: Dies bestätigt, dass ich als normaler, unprivilegierter Benutzer angemeldet bin. Die Gruppenzugehörigkeit zur Gruppe "users" ist Standard und gewährt keine besonderen Privilegien für die Privilegienerhöhung. Ich benötige einen Weg, um Root-Rechte (UID 0) zu erlangen.
Empfehlung (Pentester): Ich starte meine lokale Erkundung von einer Standard-Benutzer-Shell aus. Mein Ziel ist es, Schwachstellen zu finden, die mir ermöglichen, Code mit Root-Rechten auszuführen.
Empfehlung (Admin): Überprüfen Sie die Gruppenzugehörigkeiten der Benutzerkonten, um sicherzustellen, dass Benutzer nur Zugriff auf die Ressourcen haben, die sie benötigen.
Ich prüfe die Betriebssystem-Informationen, insbesondere den Kernel, um nach versionsspezifischen lokalen Exploits suchen zu können.
Linux atom 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux
Analyse: Der Befehl uname -a liefert detaillierte Informationen über das Betriebssystem und den Kernel. Die Ausgabe zeigt, dass es sich um ein Linux-System namens "atom" mit dem Kernel 6.1.0-21-amd64 handelt, basierend auf Debian 6.1.90-1, kompiliert am 3. Mai 2024. Die Architektur ist x86_64. Alle 'O'-Fehler wurden korrigiert.
Bewertung: Der Kernel 6.1.0 ist relativ aktuell, aber "relativ aktuell" bedeutet nicht unbedingt frei von Schwachstellen. Manchmal gibt es Kernel-Exploits, die spezifische Unterversionen betreffen. Die Information, dass es sich um ein Debian-System handelt, ist ebenfalls nützlich, da bestimmte Exploits oder Konfigurationen distributionsspezifisch sein können. Dies ist ein potenzieller Vektor, der weiter untersucht werden könnte, indem man nach bekannten Schwachstellen für diesen spezifischen Kernel (6.1.0-21) sucht.
Empfehlung (Pentester): Ich werde nach bekannten lokalen Privilegienerhöhungs-Exploits für den Linux Kernel 6.1.0-21 auf Debian-Systemen suchen. Tools wie LinPEAS oder manuelle Recherchen können hier hilfreich sein. Parallel dazu suche ich weiter nach anderen lokalen Fehlkonfigurationen oder Schwachstellen.
Empfehlung (Admin): Stellen Sie sicher, dass der Systemkernel und alle installierten Pakete regelmäßig aktualisiert und gepatcht werden, um bekannte Sicherheitslücken zu schließen. Überprüfen Sie die Kernel-Konfiguration auf gehärtete Einstellungen.
Während meiner lokalen Erkundung habe ich möglicherweise eine Systemkonfiguration oder Datei gefunden, die auf einen gehashten Benutzer hinweist, der nicht über die standardmäßigen Wege zu finden war. Basierend auf dem vorliegenden Text gehe ich davon aus, dass ich auf meiner Angreifer-Maschine einen weiteren Hash gefunden und gespeichert habe, der potenziell einem privilegierten Benutzer auf dem Zielsystem gehört. Ich versuche nun, diesen Hash zu cracken.
Using default input encoding: UTF-8 Loaded 1 password hash (crypt, generic crypt(3) [?/64]) Cost 1 (algorithm [1:descrypt 2:md5crypt 3:sunmd5 4:bcrypt 5:sha256crypt 6:sha512crypt]) is 0 for all loaded hashes Cost 2 (algorithm specific iterations) is 1 for all loaded hashes Will run 12 OpenMP threads Press 'q' or Ctrl-C to abort, almost any other key for status madison (?) 1g 0:00:00:01 DONE (2025-06-23 23:26) 0.9615g/s 276.9p/s 276.9c/s 276.9C/s kisses..sunshine3 Use the "--show" option to display all of the cracked passwords reliably Session completed.
Analyse: Ich speichere einen weiteren Hash, der im Format $2y$... beginnt (ein bcrypt-Hash), in einer Datei namens hash auf meiner Angreifer-Maschine. Anschließend verwende ich John the Ripper mit der rockyou.txt Wordlist und dem spezifischen Format --format=crypt (dieses Format kann verschiedene gehashte Passworttypen wie bcrypt verarbeiten) , um den Hash zu cracken. JtR ist erfolgreich und identifiziert das Klartextpasswort als "madison". Alle 'O'-Fehler wurden korrigiert.
Bewertung: Der Fund und das Knacken dieses bcrypt-Hashes sind ein kritischer Schritt zur Privilegienerhöhung. Bcrypt-Hashes werden oft für Systembenutzerpasswörter (einschließlich root) in der /etc/shadow Datei verwendet. Das geknackte Passwort "madison" ist sehr wahrscheinlich das Passwort für einen privilegierten Benutzer, möglicherweise root oder einen anderen administrativen Benutzer.
Empfehlung (Pentester): Ich habe nun ein potenzielles Root-Passwort (madison). Ich werde versuchen, dieses Passwort zu verwenden, um meine Privilegien von Benutzer "onida" auf Root zu erhöhen, wahrscheinlich mit dem Befehl su root.
Empfehlung (Admin): bcrypt ist ein stärkerer Hashing-Algorithmus als z.B. SHA-1 (wie bei IPMI gesehen), aber er schützt nicht vor Brute-Force mit schwachen Passwörtern. Erzwingen Sie starke, eindeutige Passwörter für alle Systembenutzer, insbesondere für privilegierte Konten. Überprüfen Sie, woher dieser Hash stammt – er könnte aus /etc/shadow stammen, was auf eine unbefugte Leseaktivität hinweisen würde, oder aus einer anderen Quelle.
Mit dem neu geknackten Passwort versuche ich nun, als Benutzer "onida" meine Identität zu Root zu wechseln.
Password: madison root@atom:/home/onida# id uid=0(root) gid=0(root) groups=0(root) root@atom:~# ls root.txt root@atom:~# cat root.txt : /` :- ..- - `- ``...-........`` `..``-://:-::.` ``.. `-` /////+++++//. `- - s////:-..-:/` `. .. +//:` +-`-` - - -://+` +/ `o` - - :/++//.` `../+ - `. `+++++///:::/+o: - - `+++///++////o: - - .++o+///////+:. - - .+o+Ns:d-s+///// `. `. :/mhMmhMyM++//-. - - -/mMMMMMMMh+/- - - +yMMMMMMN+o-` `. `.... .-:-` .. `+hMmNNhN+/+:- - .//::/// :::/::+//. - .+hNsyd/d-o---: `- ://.` ``` `::. //+ -` :++-++++++o...- `++` .+/- `- -+://++///+.-:- /// `+/+``:-///://++///+//y+.-/// -////sssooooooooosssssoo///- `.+//+ooooossoooyssoosss+//: `.```-:---///++///+++++++o+oo+++++/+/` .//++//////////++////////////++///////-`` `...` `.------..-:///////+/:://////- `-:/+++. ...` FLAG = [d3a4fd660f1af5a7e3c2f17314f4a962] <-- ROOT FLAG!
Analyse: Ich benutze den Befehl su root, um meine Identität zu Root zu wechseln. Das System fragt nach dem Passwort für Root. Ich gebe das gerade geknackte Passwort "madison" ein. Die Authentifizierung ist erfolgreich! Die Prompt wechselt zu root@atom:~#, was anzeigt, dass ich nun als Root angemeldet bin. Ich verifiziere dies mit dem id Befehl, der uid=0(root) bestätigt. Ich liste den Inhalt des Root-Verzeichnisses (ls) auf und finde die Datei root.txt. Ich lese den Inhalt dieser Datei mit cat root.txt. Die Ausgabe zeigt ASCII-Art und die Root-Flag: d3a4fd660f1af5a7e3c2f17314f4a962. Alle 'O'-Fehler wurden korrigiert.
Bewertung: Fantastisch! Die Privilegienerhöhung von Benutzer "onida" zu Root war erfolgreich! Das geknackte Passwort (madison) war tatsächlich das Passwort für den Root-Benutzer. Dies demonstriert, wie ein schwaches Root-Passwort, selbst wenn es gehasht ist (bcrypt), durch Offline-Cracking kompromittiert werden kann, was einem Angreifer vollen administrativen Zugriff auf das System gewährt. Die Root-Flag wurde erfolgreich abgerufen.
Empfehlung (Pentester): Ich habe erfolgreich Root-Zugriff erlangt und die Root-Flag abgerufen. Der Penetrationstest des Systems "Atom" ist damit abgeschlossen. Ich werde nun den Bericht finalisieren.
Empfehlung (Admin): **Dies ist eine kritische Sicherheitslücke.** Das Root-Passwort muss umgehend geändert werden. Verwenden Sie ein langes, komplexes und einzigartiges Passwort, das nicht in Wordlists enthalten ist. Erwägen Sie alternative, sicherere Methoden für die Authentifizierung von Root-Benutzern (z.B. Schlüsselpaare für SSH-Login als ein anderer Benutzer und dann su oder sudo mit einem sehr starken Passwort oder Multi-Faktor-Authentifizierung, falls möglich). Stellen Sie sicher, dass die /etc/shadow Datei angemessen geschützt ist, um unbefugtes Lesen der gehashten Passwörter zu verhindern.